【速報】もうアンチパターンとは呼ばせない！！VPC Lambdaのコールドスタート改善が正式アナウンスされました！！

CX事業本部＠大阪の岩田です。 re:invent2018にてアナウンスされたVPC Lambdaの改善について、ついにAWSより公式のアナウンスがありました！！

Announcing improved VPC networking for AWS Lambda functions

今後数カ月に渡って全リージョンで徐々にローリングアップデートが掛かっていき、展開が完了したリージョンについては上記AWSのブログが更新されるとのことです。ユーザー側では特に変更操作など必要ありません。

今までのアーキテクチャ

これまでのVPC LambdaはLambdaのサンドボックス環境を作成する際に、必要に応じてENIの作成&アタッチ処理を行なっていました。

※上記AWSのブログより引用

このアーキテクチャは以下のような課題を抱えていました。

• ENI作成を伴うコールドスタートにおいての非常に大きな遅延が発生する
  • ENI作成を伴うコールドスタートを引いた場合は10~20秒程度の大きな遅延が発生していました
• Lambda実行環境にアタッチされたENIの数だけサブネット内のIPアドレス消費する
  • Lambda実行環境が消費するIPアドレスを考慮してサブネット内のIPアドレス管理を行う必要がありました
  • AWSアカウント毎のENI上限に達するリスクがありました
  • 新しくENIを作成する際にAPIレートの制限に達するリスクがありました

これからのアーキテクチャ

これからのアーキテクチャでは、Lambda実行環境とVPCの接続にHyperplane ENIが利用されるようになります。複数のLambda実行環境がHyperplane ENIを共有し、さらにHyperplane ENIからENIにNAT処理を行うことでVPCリソースへのアクセスを実現するようです。

※上記AWSのブログより引用

Hyperplane ENIについてはこちらの動画で解説されています。 AWS re:Invent 2017 Keynote - Tuesday Night Live with Peter DeSantis

セッションレポートはこちら

【レポート】re:Invent 2017のTuesday Night LiveはAWSテクノロジーが言語化された瞬間だった #reinvent

このアーキテクチャの変更によって、以下のようなメリットが生まれます。

• コールドスタート時の遅延削減
  • Lambda関数を作成した際もしくはLambda関数のVPC設定を更新した際にENIの作成が行われ、Lambda実行時には事前作成されたENIを利用するようなアーキテクチャに変更されます。これによりENI作成と接続に必要だった遅延が大きく削減されることになります。
• ENI・IPアドレスの節約
  • 新アーキテクチャでは複数のLambda実行環境でENIを共有することになるため、サブネット内でのIPアドレスの使用数を抑えることが可能です。
• スケーリングの改善
  • LambdaのスケーリングがENIの数に直接的に依存しなくなり、多数のLambda関数同時実行がサポートされるようになります。

なお、注意点として以下の事項については新アーキテクチャでも変更はありません。

• Lambda実行ロールにはENIの作成・削除権限が必要
• サブネットとセキュリティグループの構成は引き続き利用可能
• インターネットアクセスにはNATゲートウェイ等のNATデバイスもしくはVPCエンドポイントが必要
• Lambdaからアクセス可能なVPCリソースの種類

上記AWSのブログではX-RAYによる新・旧アーキテクチャの比較画像が掲載されていました。新アーキテクチャではコールドスタートが1秒未満で完了していることが分かります。

やってみる

バージニアリージョンで試しましたが、まだ新環境への移行が進んでいないのか、それとも運の問題なのか新アーキテクチャでのLambda起動を引き当てられませんでした...

注意！！

煽り気味なタイトルを書いておいて、申し訳無いのですがVPC LambdaやLambda x RDBの構成が抱える懸念点はコールドスタートの遅延だけではありません。このあたりの情報も参照された上で、自身のユースケースに問題ないかを再確認頂ければと思います。

• なぜAWS LambdaとRDBMSの相性が悪いかを簡単に説明する
• Serverless Meetup Osaka #5 で「VPC Lambda×RDSのデメリットについて正しく理解しよう！!」というテーマで発表してきました #serverlessosaka

まとめ

VPC Lambdaのコールドスタート改善に関してご紹介しました。 これは非常に嬉しいアナウンスですね！！ 実際に触れなかったのでAWSのブログを引用しただけのポストになってしまいましたが、リリース状況を日々チェックしながら、リリースされ次第即触り倒していきます。

DBの選定は特性に応じた適材適所な選定が重要なので、単純に「今後はLambdaの開発も全部RDBで良いやん！！」と考えるのは危険ですが、それでも選択肢の幅が大きく広がったことは間違いありません。 Lambdaを利用したシステム開発において、VPC Lambdaのコールドスタートによる遅延を理由にRDBの採用を見送っていたケースは非常に多いと思いますが、今回のアップデートを機にもう一度検討してみてはいかがでしょうか？